Tomcat, Netty, NGINX, Apache HTTP Server: 심층 비교

아래는 널리 사용되는 네 가지 서버 기술 — Tomcat, Netty, NGINX, Apache HTTP Server (httpd) — 에 대한 아키텍처, 운영 방식, 성능, 확장성, 사용 사례 등을 중심으로 매우 상세하게 비교한 설명입니다.

1. Tomcat

개요

• 종류: Java Servlet/JSP 컨테이너 (Java 웹 애플리케이션용 앱 서버)
• 적합한 용도: Servlet, JSP, JavaEE 기반의 웹 애플리케이션 실행
• 출처: Apache Software Foundation이 개발했고, Servlet 사양의 참조 구현입니다.

아키텍처 구성

• Catalina (서블릿 컨테이너): HTTP 요청을 Servlet 및 JSP로 라우팅하고, 생명주기 관리
• Connector: HTTP/HTTPS 커넥션 수신 및 프로토콜 처리
• Container: 개별 웹 애플리케이션을 관리하며, WAR 파일 혹은 디렉터리 배포 관리
• Manager UI/API: 웹 기반 GUI 또는 REST API를 통한 앱 배포, 상태 확인, 중지/시작 등 지원

처리 방식

• 요청당 스레드 모델(Thread-per-request): 요청 하나당 스레드 하나 할당 (thread pool 제한에 따라 동시성 한계 존재)
• 기반: JVM 위에서 Java 코드 실행, HTTP/HTTPS/WebSocket 지원, 주로 Java Servlet 등 실행에 특화됨

장점

• Java EE 사양 완전 지원 (서블릿, JSP, 필터, 리스너 등)
• WAR 파일 배포 편리 / Gradle, Maven 등 빌드툴과 연동 용이
• 성숙한 생태계, 안정성 높음
• Java 웹 개발에 특화된 구조

한계

• Java 전용 ⇒ Java 아닌 서버 목적에는 부적합
• Node.js나 Netty처럼 대규모 동시 연결 스케일링은 어려움
• 많은 요청 시 메모리 사용량 증가 (스레드 기반 처리 구조)

2. Netty

개요

• 종류: Java용 이벤트 기반 논블로킹 네트워크 프레임워크 (NIO 기반)
• 적합한 용도: 고성능 네트워킹, 사용자 정의 프로토콜 서버, WebSocket, gRPC, Microservice backend 등
• 출처: Netty Project, Spring WebFlux 같은 reactive 프레임워크들이 내부적으로 사용

아키텍처 구성

• Channel: 소켓/파일 연결 추상화. 항상 논블로킹
• Event Loop(Reactor): CPU 코어당 1~2개 스레드로 수천 개의 연결 처리
• Pipeline/Handler 체계: 요청은 여러 핸들러를 순차적으로 거쳐 처리 → 커스터마이징 용이
• Zero-Copy 및 버퍼 관리: 성능 극대화를 위한 효율적인 메모리/IO 처리

처리 방식

• NIO 기반 논블로킹 구조: 요청 수천/수만 개 동시 처리 가능
• 다양한 프로토콜 지원: HTTP, TCP, UDP, WebSocket, 사용자 정의 바이너리/텍스트 프로토콜 등
• 엔진 역할: Spring WebFlux, gRPC, Netty 서버 자체 등 다양한 고성능 Java 네트워크 애플리케이션에서 사용

장점

• 무한에 가까운 동시성 성능 (실시간 서비스에 적합)
• 요청당 스레드 필요 없음 → 메모리 효율 매우 좋음
• 프로토콜, 파이프라인 구조 완전 커스터마이징 가능

한계

• 학습 곡선이 가파름: 저수준 코드 많음
• 일반적인 웹 서버처럼 바로 쓸 수 없음 (기능 직접 구현 필요)

3. NGINX

개요

• 종류: 고성능 이벤트 기반 웹 서버, 리버스 프록시, 로드 밸런서, API 게이트웨이
• 적합한 용도: 정적 파일 서비스, SSL 종료, 백엔드 앱서버 프록시(Tomcat, Node 등), 캐시와 로드밸런싱, API 프록시

아키텍처 구성

• 마스터-워커 구조: 마스터 프로세스가 여러 워커 프로세스를 관리
• 이벤트 루프 기반 워커: 각 워커는 수천 개의 연결을 논블로킹 이벤트 방식으로 처리
• 모듈화 기반 구조: gzip, 캐싱, WAF, http_rewrite 등 다양한 모듈 사용 가능

처리 방식

• 정적 파일 전송 최적화: HTML, 이미지, 비디오 등 빠르게 전달
• 리버스 프록시 역할: 외부 요청을 내부 앱 서버(Tomcat 등)로 포워딩, SSL 오프로딩 수행
• API 게이트웨이 역할: 여러 내부 서비스에 클라이언트 요청 라우팅

장점

• 매우 높은 성능과 낮은 메모리 소비
• 설정이 간단하고 확장성 높음
• 거의 모든 대형 사이트에서 사용 (Netflix, Amazon 등)

한계

• Java 코드를 실행하거나 Servlet을 직접 제공하지 않음
• 동적 콘텐츠 생성은 백엔드(app 서버) 의존적이며 자체적으로는 지원 불가

4. Apache HTTP Server (httpd)

개요

• 종류: 전통적인 범용 웹 서버
• 적합한 용도: 정적 웹 호스팅, PHP, CGI, 리버스 프록시, 호환성 높은 일반 웹 서비스
• 출처: Apache Software Foundation에서 1990년대부터 개발

아키텍처 구성

• 모듈 기반 구성: SSL, PHP, proxy, gzip 등 기능은 모듈로 확장 가능
• 다양한 MPM 지원: process/thread/event 기반 MPM (multi-processing module) 선택 가능
• 설정 방식: httpd.conf 등의 텍스트 설정 매우 유연하지만 복잡할 수 있음

처리 방식

• 선택형 MPM 구조:
  • prefork: 요청당 별도 프로세스(안정성 높음, 메모리 소모 큼)
  • worker: 스레드 기반
  • event: 논블로킹식 처리 및 Keep-Alive 지원
• CGI, PHP 등 스크립트 기반 동적 페이지 지원
• 가상 호스팅, MIME 타입 관리 등 일반 HTTP 기능 매우 강력함

장점

• 매우 성숙하고 확장성 강한 웹 서버
• .htaccess 및 접근 제어 등 보안 옵션 우수
• PHP 등 스크립트 처리 기능 내장 / 잘 통합됨

한계

• Java Servlet 실행 불가 (대신 Tomcat 등으로 프록시해야 함)
• 다수 동시 연결 처리 성능은 NGINX보다 낮음
• 설정이 복잡하고 verbose함

종합 비교 표

실제 사용 예

• Java 애플리케이션:
  NGINX 또는 Apache → Tomcat

• 고성능 Netty 앱:
  NGINX → Netty 기반 서버

• 정적 콘텐츠/멀티 API 게이트웨이:
  NGINX 단독 또는 NGINX → 내부 백엔드

• PHP 웹사이트:
  Apache HTTP Server

언제 무엇을 써야 하나?

결론

참고: 실제 시스템 아키텍처에서는 이들을 함께 사용하는 사례가 많습니다.
예:

• NGINX가 앞단에서 SSL 처리 및 리버스 프록시 역할
• Tomcat 또는 Netty가 백엔드 애플리케이션 처리 담당